When restoring a database to a MiVoice Business system which is different from the one on which the database was backed up, the licenses, configuration options, and dimension selection programming on the target system must be adequate to support the requirements from that database. If you restoring to a different system, ensure that the licensing, configuration options, and dimension selection match the original system.
Restoring a database from one platform type (AX, CX II, CXi II, MXe III) to another requires that the two databases match in the modules and add-ons, including embedded analog circuits programmed.
For example:
You can restore a database from a CX II or CXi II to an MXe III controller; however, the Layer 2 switch on the MXe will require configuring after the Restore. The AMB and AOB may also require re-configuration.
You can only restore an AX controller database to an AX controller. You cannot restore a database from another type of controller to an AX controller.
You can restore a database from an EX controller to a CX II or CXi II to an MXe III controller, and vice versa.
When restoring a database, if the IP address in it doesn't match the one in the target MiVoice Business system (the system you are restoring the database to), then the database is considered foreign.
Restoring foreign databases is supported in MCD Release 5.0 and later. errors, particularly in the Network and Cluster Elements forms and the Admin Group form
IMPORTANT: To restore a foreign database in an SDS data-sharing network, the database must not already exist on any element in the network. For example, in an SDS network of three nodes, A, B, and C, you cannot restore a database to Node A if it was taken from either Node B or C. Furthermore, the Restore Foreign Database feature is NOT a substitute for performing an SDS sync to distribute data. When adding a new node to an existing network, the proper procedure is to start sharing from an existing node, and then perform a full sync from that node to the new node. See Unsupported Uses for Foreign Databases for additional information regarding unsupported uses for Foreign Databases.
The following are recommended ways to use foreign databases:
A dealer may want to set up a “Gold” database that contains commonly programmed system data—for example, COS, COR, System Options, etc. Rather than repeatedly entering the common data for each customer, the dealer can program it once in his lab and back it up to create a Gold database. He can then restore that database to controllers at multiple customer sites and reprogram the IP addresses in them to align with each customer's network.
Normally, no user or device data is included in the Gold database so licensing isn’t a concern. If licensed data is added, then the dealer would need to license the lab system before programming the users or devices. Even with the introduction of license violation mode in MCD 5.0, licensing is still required, as you cannot enter license violation mode without first communicating with the AMC, a process which involves hardware identification.
Dealers who prefer to work in their labs instead of at the customer's site can use a Foreign Database to set up systems. The dealer typically has his own licensed lab hardware that uses an IP addressing scheme different than the one the customer has. With the Foreign Database feature, the dealer does not need to worry about matching destination IP addresses (or the customer changing destination IP addresses without notice). He can commission the systems, back them up, and then restore at the customer’s site, on different hardware, with different IP addresses. The only additional step, if the systems are clustered, is to re-initiate SDS sharing.
Foreign Database Restore is a useful way to start building a cluster either on the customer’s premises or in the dealer’s lab.
A) Building a cluster at the customer’s site
To build a cluster at a customer site:
Make a Gold database that has all the cluster elements programmed in the Network Elements form.
Restore the database to a single element in the cluster.
Use SDS to share, then sync, the data to all other nodes in the network.
B) Building a cluster using a single MiVoice Business system at the dealer’s site
To build a cluster offsite—in a dealer’s lab, for example—using a single MiVoice Business system, start with a full install of the MiVoice Business software with licensing to allow cluster and device programming. Then, proceed as follows to create databases for each element in the cluster:
Program the first cluster element (Element A) with users and devices (this case assumes no resiliency)
Back up the database.
Do another full install (to clear the database) and re-license.
Program users and devices for the second element (Element B)
Do another database backup.
Repeat steps 3-5 for each element in the cluster.
At the customer’s site,
Restore the databases to their corresponding elements.
From one cluster element, add the names and IP addresses of the other elements to the Network Element form.
Create the cluster.
Start sharing data via SDS.
Finish by synchronizing at least the data in the Telephone Directory, User, and Service Hosting data.
C) Building a cluster at the dealer’s site using multiple MiVoice Business systems
This use case is a variation on the preceding one. The difference is that the dealer is using multiple systems to configure the databases, essentially replicating the customer’s network in his lab. As in the previous case, the dealer is required to license the systems to allow cluster and device programming.
To build the cluster, follow the usual procedure—enter the cluster members into the Cluster Element form on one of the systems, and then start sharing data via SDS to the other clusters elements.
Complete the system programming (e.g., trunks, COS, etc.) and add the users and devices.
Back up the databases on each system.
At the customer’s site,
Restore the backups to the customer's systems.
Re-align the IP Addresses of all other nodes in the network, then start sharing from that node.
After sharing, all databases will be in-sync, and IP addresses will match.
In general, Foreign Databases are best used in greenfield installations or following a Full Install (which deletes the existing database) of MiVoice Business software on a previously commissioned system. Using them in other scenarios is not recommended and should be avoided altogether in the following instances:
Restoring a Foreign Database backup from a system that was already a member of the same SDS network as the Restore destination is not supported—in fact, the Restore fails. For example, in a network of nodes sharing via SDS, restoring a backup from network element B to network element A will fail.
IMPORTANT: This Restore failure is only detected AFTER the first reboot and isn’t evident unless you are monitoring the RTC shell or examining the ESM logs. Further, the database that was previously in place is NOT be preserved.
Consider two independent clusters, A and B. It is possible to take a database backup from a member of cluster A and restore it to a member of cluster B. In this case, the Restore will work since the backup database complies with the rule that it must not come from a system that is already a member of the same SDS network as the Restore destination. The mistake becomes apparent when SDS tries to sync the databases and encounters inconsistencies which result in SDS errors.
Restoring a database backup from an Enterprise licensed system to Standalone licensed system is not supported. The inverse is possible, but you lose support for resiliency and the other features that Enterprise licensing provides.